Как многие из вас знают, в последние пару лет очень сильно увеличилось число и масштаб атак, связанных с уязвимостями в аппаратном обеспечении. Наибольшую известность получили уязвимости Meltdown и Spectre, которые были обнаружены в процессорах Intel.
Самый неприятный момент, связанный с подобного рода уязвимостями - это то, что поскольку они связаны с аппаратной частью процессоров на самом низком уровне, то, во-первых, ее сложнее исправить и доставить конечным пользователям, а, во-вторых, неправильное обновление, закрывающее эти дырки, может вызвать различные побочные эффекты.
Так, например, было с производительностью серверов VMware ESXi, когда производители ОС совместно с Intel выпустили соответствующие обновления, а VMware выпустила закрывающий уязвимость патч. Сам патч тогда пришлось отозвать и ждать нового, а ведь это потраченного время администраторов, время пользователей и время, в течение которого существует угроза безопасности инфраструктуры предприятия.
Поэтому производители процессоров, совместно с вендорами платформ виртуализации, сейчас уделяют этому моменту особое внимание. Конечно же, в этом направлении работает и AMD, которая активно внедряет следующие технологии:
Secure Encrypted Virtualization (SEV) - первая версия технологии, анонсированная в 2016 году. Она позволяет изолировать виртуальные машины от гипервизора, со стороны которого может быть угроза безопасности при его компрометации. Если гипервизор попытается считать память гостевой ОС, он увидит только зашифрованные данные.
SEV-ES (Encrypted State) - вторая версия технологии, представленная в 2017 году. Она дополняет защиту памяти гостевой ОС шифрованием регистров CPU гостевой ОС. Таким образом, гипервизор не может видеть регистры процессора, активно используемые виртуальной машиной.
SEV-SNP (Secure Nested Paging) - следующее поколение технологии, которое было анонсировано в этом году. Оно добавляет функции аппаратной безопасности для контроля над интеграцией памяти гостевых ОС, что защищает от таких атак, как data replay, memory re-mapping и других (подробнее тут и на картинке ниже).
В недавнем обновлении платформы виртуализации VMware vSphere 7 Update 1 появилась поддержка технологии SEV-ES (Encrypted State), которая должна еще больше защитить от потенциальных уязвимостей, связанных с доступом к данным в рамках процессора. Работает это на процессорах AMD EPYX 7xx2 CPU
или более поздних и требует VM Virtual Hardware версии 18, которое появилось в Update 1.
Надо начать с того, что у VMware уже есть защита памяти и данных гостевой ОС на уровне платформы (а в самих ОС тоже есть средства защиты памяти и процессора), но, само собой, эти механизмы на надежны на 100%, потому что ключевой компонент платформы - гипервизор, обладает очень широкими полномочиями (в виду необходимости), и при его компрометации ничего особо не поможет. Поэтому самое разумное - это поддержать подход изоляции ВМ от гипервизора на аппаратном уровне. Он, кстати, называется Trusted Execution Environment (TEE).
Подход AMD заключается в том, что они добавляют специальный Secure Processor, маленький сопроцессор, интегрированный в основной чип CPU, который является основой безопасности и поддерживает операции шифрования, в том числе и для SEV-ES.
Первое поколение EPYC CPU поддерживало хранение только 15 ключей шифрования, но следующее поколение уже поддерживает более 500. Один из таких ключей используется для гипервизора, а остальные - для гостевых систем.
Для чего вообще нужно защищать регистры процессора гостевых систем? Очень просто - когда виртуальная машина переключает контекст исполнения (меняет процессор), гипервизор получает ресурсы CPU обратно, вместе с содержимым регистров. А в них может храниться много "полезного" для злоумышленника - например, ключи для расшифровки дисков гостевой системы.
Работает механизм ключей так - гостевая ОС запрашивает у процессора с поддержкой SEV ключ шифрования для памяти, а SEV-ES расширяет его и на регистры процессора тоже, после чего гостевая ОС может безопасно использовать память и регистры, не беспокоясь что гипервизор или другие ВМ, изолированные в рамках процессов VMX, считают их содержимое. Очевидно, что гостевая ОС тоже должна поддерживать реализацию SEV-ES (поэтому надо читать соответствующую документацию к ним, чтобы узнать о поддержке).
Самым большим минусом использования технологии SEV-ES является невозможность поддержки таких техник, как vMotion, Memory Snapshots, Guest Integrity, Hot Add, Suspend & Resume, Fault Tolerance и горячих клонов - ведь для их реализации гипервизор должен иметь прямой доступ к памяти гостевых систем. В то же время надо отметить, что это не ограничение от AMD, которая заявляет, что SEV поддерживает live migration и прочее, а ограничение реализации от VMware.
В большинстве производственных окружений невозможность применения этих технологий будет ограничивать использование SEV-ES только системами, требующих наивысшего уровня защищенности.
С другой стороны, например, недавно вышедшее решение vSphere with Tanzu не использует vMotion для машин с контейнерами виртуализованных приложений - они просто выключаются на одном хосте и включаются на другом, то есть здесь есть перспективы применения SEV-ES.
Также использованием технологии SEV-ES можно управлять в пакетном режиме сразу для нескольких тысяч виртуальных машин через интерфейс PowerCLI, что особенно актуально для контейнеров Tanzu. На данный момент VMware еще не опубликовала официальный референс по командлетам для SEV-ES, ждем.
Ну и недавно VMware выпустила интересное видео, рассказывающее о первой имплементации технологии SEV-ES в платформе VMware vSphere 7 Update 1:
Как итог можно отметить, что пока такие технологии, как Secure Encrypted Virtualization имеют достаточно узкое применение ввиду их ограничений. Однако это лишь первые шаги, которые производители процессоров делают совместно с вендорами платформ виртуализации, чтобы защитить ИТ-среду предприятия он новой волны атак на программно-аппаратную инфраструктуру датацентра. Дальше все это будет развиваться, будет и поддержка AMD SEV-SNP, что уже будет существенно уменьшать поверхность возможных атак.
Одной из новых возможностей VMware vSphere 7 U1 стала служба vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter.
Как вы знаете, кластер HA/DRS очень зависит от постоянной доступности сервисов vCenter, который является критическим звеном виртуальной инфраструктуры. Поэтому для него организовывают такие сервисы, как vCenter Server High Availability (VCHA), но и они не идеальны. Также проблема наблюдается при масштабировании кластеров в больших окружениях, которые объединяют онпремизные и облачные площадки, где масштабируемость vCenter является серьезной проблемой.
Учитывая это, VMware придумала такую штуку - сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом:
Таких виртуальных машин три в кластере, где 3 или более хостов, и две, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.
Три этих виртуальных машин следят друг за другом и оповещают об этом кластерные службы vCenter:
Это самокорректирующийся механизм, что значит, что если одна из агентских машин становится недоступной или выключенной, то службы vCLS пытаются самостоятельно наладить работу ВМ или включить ее.
Есть 3 состояния служб vCLS:
Healthy – как минимум 1 агентская ВМ работает в кластере, чтобы обеспечить доступность кластера развертываются 3 ВМ для кворума.
Degraded – как минимум одна агентская машина недоступна, но DRS продолжает функционировать и исполнять свою логику. Такое может, например, произойти при передеплое служебных машин vCLS или после какого-то события, повлиявшего на их "включенность".
Unhealthy – логика DRS не выполняется (балансировка или размещение ВМ), так как vCLS control-plane недоступна (то есть ни одной агентской ВМ не работает).
Легковесные машины-агенты исполняются на хостах ESXi и лежат на общих хранилищах, если общие хранилища недоступны - то на локальных дисках. Если вы развернули общие хранилища после того, как собрали кластер DRS/HA (например, развернули vSAN), то рекомендуется перенести агентские ВМ с локальных хранилищ на общие.
Сама гостевая ОС агентских ВМ очень легковесная, используется Photon OS следующей конфигурации:
Диск в 2 ГБ - это тонкий диск, растущий по мере наполнения данными (thin provisioned). Эти машины не имеют своего нетворка, а также не видны в представлении Hosts and Clusters в клиенте vSphere.
Агентские ВМ можно увидеть в представлении VMs and Templates где есть папка vCLS:
Обратите внимание, написано, что для агентских ВМ управление питанием производится со стороны служб vCLS. Если вы попытаетесь выключить эти ВМ, то будет показано следующее предупреждение:
При переводе кластера в режим обслуживания vCLS сам заботится о миграции агентских ВМ с обслуживаемых серверов и возвращении их обратно. Для пользователя это происходит прозрачно. И, конечно же, лучше не выключать эти ВМ вручную и не переименовывать папки с ними.
Жизненный цикл агентских ВМ обслуживается со стороны vSphere ESX Agent Manager (EAM).
EAM отвечает за развертывание и включение агентских ВМ, а также их пересоздание, если с ними что-то произошло. В анимации ниже показано, как EAM восстанавливает ВМ, если пользователь выключил и/или удалил ее:
Важный момент для разработчиков сценариев PowerCLI - это необходимость обрабатывать такие ВМ, чтобы случайно не удалить их. Например, ваш скрипт ищет неиспользуемые и забытые ВМ, а также изолированные - он может по ошибке принять машины vCLS за таковые и удалить, поэтому их надо исключать в самом сценарии.
В интерфейсе vSphere Client список агентских ВМ можно вывести в разделе "Administration > vCenter Server Extensions > vSphere ESX Agent Manager".
У агентских ВМ есть свойства, по которым разработчик может понять, что это они. В частности:
ManagedByInfo
extensionKey == "com.vmware.vim.eam"
type == "cluster-agent"
ExtraConfig keys
"eam.agent.ovfPackageUrl"
"eam.agent.agencyMoId"
"eam.agent.agentMoId"
Основное свойство, по которому можно идентифицировать агентскую ВМ, это HDCS.agent, установленное в значение "true". В Managed Object Browser (MOB) выглядит это так:
Ну и напоследок - небольшое демо технологии vSphere Clustering Service:
На сайте проекта VMware Labs вышла очередная полезность - сценарий для интеграции VMware vRealize Network Insight (vRNI) и VMware HCX. Напомним, что vRNI - это решение для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений, а HCX - продукт для миграций с различных опремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud.
С помощью данного скрипта администраторы VMware vSphere могут упростить и ускорить процесс миграции виртуальных машин. Сначала сценарий за счет vRNI обнаруживает приложение и его границы использования сети и ресурсов в рамках виртуальной машины, после чего создает под него структуры внутри самого vRNI.
Затем эти vRNI application constructs интегрируются в объекты HCX Mobility Groups, экономя время на ручное создание этих сущностей. После подготовки объектов вы можете начать сам процесс миграции виртуальных машин.
Для работы сценария оба продукта vRNI и HCX должны иметь лицензию Enterprise, также у вас должны быть установлены модули PowervRNI and the PowerCLI HCX.
Пример использования сценария:
$vrni_pw = ConvertTo-SecureString 'admin' -AsPlainText -Force
$hcx_pw = ConvertTo-SecureString 'VMware1!' -AsPlainText -Force
./sync-vrni-to-hcx.ps1 -vRNI_Server 10.196.164.134 -vRNI_Username admin@local -vRNI_Password $vrni_pw -HCX_Server hcxe.vrni.cmbu.local -HCX_Username hcx@cmbu.local -HCX_Password $hcx_pw -HCX_DestinationVC vc-pks.vrni.cmbu.local -HCX_DestinationCloud hcxc.vrni.cmbu.local
[03-05-2020_05:19:59] Connecting to vRealize Network Insight..
[03-05-2020_05:20:01] Retrieving all applications..
[03-05-2020_05:20:20] Found application: 'onprem_imagic' with 6 VMs
[03-05-2020_05:20:22] Found application: '3TierApp02' with 1 VMs
[03-05-2020_05:20:25] Found application: 'HIVE Training' with 1 VMs
[03-05-2020_05:20:27] Found application: 'VDI Pool 1' with 8 VMs
[03-05-2020_05:20:29] Found application: 'app_mcclanahanc' with 2 VMs
[03-05-2020_05:20:31] Found application: 'Top-Video' with 15 VMs
[03-05-2020_05:20:33] Found application: 'F5-3TierApp05' with 5 VMs
[03-05-2020_05:20:34] Connecting to VMware HCX..
[03-05-2020_05:20:48] Created Mobility Group: 'onprem_imagic_2020-03-05'
[03-05-2020_05:20:49] Created Mobility Group: '3TierApp02_2020-03-05'
[03-05-2020_05:20:50] Created Mobility Group: 'HIVE Training_2020-03-05'
[03-05-2020_05:20:51] Created Mobility Group: 'VDI Pool 1_2020-03-05'
[03-05-2020_05:20:52] Created Mobility Group: 'app_mcclanahanc_2020-03-05'
[03-05-2020_05:20:53] Created Mobility Group: 'Top-Video_2020-03-05'
[03-05-2020_05:20:54] Created Mobility Group: 'F5-3TierApp05_2020-03-05'
Коллега с virten.net написал замечательную статью об использовании сетевых адаптеров USB на хостах VMware ESXi, основные моменты которой мы приведем ниже.
Напомним, что подключить сетевые адаптеры USB на хостах ESXi можно с помощью драйвера USB Network Native Driver for ESXi, о котором мы не так давно писали вот тут. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.
Еще один вариант использования таких адаптеров - когда у вас (например, на тестовом сервере) есть всего один гигабитный порт, а вам нужно тестировать технологии и продукты, где нужно несколько высокоскоростных соединений.
Итак, после того, как вы скачаете драйвер, его установка делается одной командой:
С помощью PowerShell можно создать кастомизированный образ ESXi с уже вшитым драйвером сетевого USB-адаптера. Просто раскомментируйте строчку с нужной версией драйвера:
# ESXi 7.0 Image with USB NIC Fling 1.6:
$baseProfile = "ESXi-7.0.0-15843807-standard" # See https://www.virten.net/vmware/vmware-esxi-image-profiles/ for available Image Profiles
$usbFling = "ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip" # Uncomment for ESXi 7.0
#$usbFling = "ESXi670-VMKUSB-NIC-FLING-39203948-offline_bundle-16780994.zip" # Uncomment for ESXi 6.7
#$usbFling = "ESXi650-VMKUSB-NIC-FLING-39176435-offline_bundle-16775917.zip" # Uncomment for ESXi 6.5
При установке VMware ESXi на хост, где есть только USB сетевые адаптеры, процесс может зависнуть на 81%. В этом случае почитайте вот эту статью.
Кстати, ваши USB-адаптеры лучше всего пометить наклейками. Автор предлагает указать имя хоста ESXi, MAC-адрес адаптера и его номер vusbX:
Номер виртуального vusbX не сохраняется при перезагрузках. Начиная с версии драйвера 1.6 можно закрепить MAC-адрес за нужным vusbX. Сначала найдем наш адаптер:
# esxcli network nic list |grep vusb |awk '{print $1, $8}'
vusb0 00:23:54:8c:43:45
vusb1 a0:ce:c8:cd:3d:5d
Затем сделаем статический маппинг адаптеров с использованием модуля vmkusb_nic_fling:
# esxcli system module parameters set -p "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d" -m vmkusb_nic_fling
В данной команде нужно перечислить все адаптеры через пробел (если вы вызываете ее второй раз, то нужно переуказать каждый из адаптеров, иначе маппинг сбросится).
Далее нужно проверить маппинги с помощью команды:
# esxcli system module parameters list -m vmkusb_nic_fling
Name Type Value Description
-------------------------- ------ ----------------- -----------
usbCdromPassthroughEnabled int Enable USB CDROM device for USB passtrough: 0 No, 1 Yes
vusb0_mac string 00:23:54:8c:43:45 persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac string a0:ce:c8:cd:3d:5d persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac string persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac string persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac string persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac string persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac string persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac string persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx
Если вы хотите сделать текущий маппинг постоянным, то используйте команду:
# esxcli system module parameters set -p "$(esxcli network nic list |grep vusb |awk '{print $1 "_mac=" $8}' | awk 1 ORS=' ')" -m vmkusb_nic_fling
Также статические маппинги можно сделать и через PowerCLI. Выводим адаптеры:
PS> Get-VMHostNetworkAdapter -VMHost esx2.virten.lab -Physical -Name vusb* |select Name,Mac
Name Mac
---- ---
vusb0 00:23:54:8c:43:45
vusb1 a0:ce:c8:cd:3d:5d
Далее проводим операцию vMotion виртуальной машины между хостами ESXi. Результат таков:
Очевидно, кросс-соединение на адаптерах 2.5G рулит.
Проверка совместимости
Не все сетевые адаптеры USB поддерживаются нативным драйвером. Их актуальный список всегда можно найти вот тут. Вот эти адаптеры точно работают:
Адаптеры доступны в форм-факторах USB-A и USB-C. Между ними есть переходники.
Если вам нужно высокоскоростное соединение (multi-gigabit) между несколькими хостами, можно посмотреть на следующие коммутаторы:
MikroTik CRS305-1G-4S+IN ($130 USD) - 4 порта
MikroTik CRS309-1G-8S+IN ($260 USD) - 8 портов
Netgear MS510TX ($260 USD) - 10 портов
TRENDnet TEG-30102WS ($450 USD) - 10 портов
Самое быстрое и дешевое соединение между двумя хостами ESXi - соединить адаптеры патч-кордом напрямую:
Проверяйте параметр MTU size, когда включаете Jumbo Frames
Если вы меняете размер MTU на виртуальном коммутаторе, он принудительно меняется на всех подключенных к нему физических сетевых адаптерах. Имейте в виду, что эти адаптеры должны поддерживать выставляемый MTU size.
Посмотреть размер MTU можно следующей командой:
[root@esx4:~] esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 0000:00:1f.6 ne1000 Up 1000Mbps Full 00:1f:c6:9c:47:13 1500 Intel Corporation Ethernet Connection (2) I219-LM
vusb0 Pseudo uether Up 1000Mbps Full 00:24:9b:1a:bd:18 1600 ASIX Elec. Corp. AX88179
vusb1 Pseudo uether Up 1000Mbps Full 00:24:9b:1a:bd:19 1500 ASIX Elec. Corp. AX88179
В данном примере MTU size настроен как 1600, что подходит для адаптеров (и работает для сети NSX-T). Если же вы поставите его в 9000, то увидите в vmkernel.log ошибки для dvSwitch о том, что такой размер не поддерживается устройством:
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: vmkusb: Set MTU 9000 is not supported: Failure
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: Uplink: 16632: Failed to set MTU to 9000 on vusb0
Если вы хотите проверить корректность вашего MTU size, то можно использовать команду ping с размером пакета MTU-28 байт (8 байт на заголовок ICMP и 20 байт на заголовок IP). Таким образом, для MTU size 1600 используйте число 1572:
[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1572 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1572 data bytes
1580 bytes from 192.168.225.10: icmp_seq=0 ttl=64 time=0.680 ms
[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1573 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1573 data bytes
sendto() failed (Message too long)
На сайте проекта VMware Labs появились обновления сразу трех интересных утилит. Давайте посмотрим, что там появилось нового:
1. Обновление FlowGate 1.1.2
Напомним, что FlowGate представляет собой средство для агрегации данных из различных источников. Это middleware, которое позволяет провести агрегацию данных систем инвентаризации датацентров DCIM / CMDB и далее передать их в системы управления задачами инфраструктуры (например, vRealize Operations).
Давайте посмотрим, что нового в версии FlowGate 1.1.2:
Добавлена поддержка шасси (Chassis) в API-интерфейсе
2. Новая версия Demo Appliance for Tanzu Kubernetes Grid 1.1.3
Напомним, что это виртуальный демо-модуль, с помощью которого администраторы платформ vSphere и Kubernetes могут протестировать инфраструктуру контейнеризованных приложений в виртуальных машинах.
Что нового в версии 1.1.3:
Поддержка последнего релиза TKG 1.1.3
Поддержка рабочего процесса апгрейда TKG Workload Cluster на K8s 1.17.9 с версии 1.18.6
Утилита TKG Crash Diagnostic utility (для отладки падений) в составе виртуального модуля
Утилита Helm (3.2.4), включенная в состав модуля
Обновленные версии Harbor (1.10.3), Docker Compose (1.26.2), Kubectl (1.18.6), Octant (0.14.1) и TMC (d11404fb) CLI в составе виртуального модуля
Сценарий PowerCLI для автоматизации проверок запуска TKG на VMware Cloud on AWS
Скачать Tanzu Kubernetes Grid 1.1.3 можно по этой ссылке.
Некоторые из вас знают, что есть такое решение VMware vRealize Network Insight (vRNI), которое предназначено для мониторинга и защиты сетевой инфраструктуры виртуальной среды VMware vSphere.
Администраторам виртуальной инфраструктуры часто приходится делать копии различных ее управляющих компонентов, в том числе vRNI. Сейчас VMware рекомендует делать резервную копию конфигурации vRNI на уровне всей виртуальной машины (см. KB 55829). Рекомендуется выключить ВМ с vRNI, скопировать ее целиком, а потом включить снова - это единственный поддерживаемый способ на данный момент.
Martijn Smit опубликовал интересный пост о том, что на самом деле у vRNI есть способ резервного копирования и восстановления конфигурации через API, для которого есть специальный API endpoint по пути /settings/backup:
Если посмотреть внутрь, то там можно увидеть вполне работоспособный механизм бэкапа конфигурации vRNI:
Используя API endpoint /api/ni/settings/backup,вы можете создать резервную копию конфигурации vRNI и перенаправить ее по SSH или FTP на бэкап-сервер в виде tar-файла со следующим содержимым:
Большинство этих файлов человекочитаемы, если вы откроете их в текстовом редакторе. Там находятся копии настроек приложений, объектов pinboards, data sources, сохраненный поиск, системные настройки (Syslog, SMTP и т.п.), пользовательские конфигурации и многое другое.
Для работы с конфигурациями vRNI через API Martijn сделал модуль PowervRNI. Вот пример использования сценария резервного копирования:
На блогах VMware вышла отличная статья про безопасность виртуальных машин и виртуальной инфраструктуры VMware vSphere в целом, расскажем ниже ее основные моменты.
Как известно, одним из действенных способов атак на виртуальную инфраструктуру vSphere является проведение злоумышленником вредоносных действий из виртуальной машины, которая потом уничтожается, часто не оставляя следов и записанных действий. Еще один интересный способ со спецификой виртуализации - украсть виртуальную машину (например, контроллер домена) и ковыряться в ней уже в своей песочнице, чтобы вытащить нужную информацию.
На этом уровне важной составляющей является пакет VMware Tools, имеющий широкие возможности доступа к виртуальной машине - ОС и приложениям. Управление поведением тулзов происходит с помощью вот этих утилит:
Само собой приведенные ниже рекомендации - это руководство для параноиков (но, как говорит Эндрю Гроув - выживают только параноики), потому что безопасность, как вы знаете - это всегда компромисс между удобством и маниакально-призрачным ощущением защищенности.
И вот тут рекомендуется принять во внимание следующие факторы на уровне VMware Tools:
1. Отключить синхронизацию времени с хостом VMware ESXi
Время - очень важная категория в контексте безопасности. Оно важно для логов, для синхронизации событий аутентификации и прочего. По-хорошему, гостевая ОС должна получать время от NTP-сервера, а не от ESXi, который может быть скомпрометирован. Если вы сомневаетесь, что у вас настроено иначе, нужно принудительно отключить синхронизацию времени с хостом. Делается это следующей командой:
VMwareToolboxCmd.exe timesync disable
2. Отключить автообновление VMware Tools
Если у вас в компании принято, что рабочий процесс обновления системных компонентов должен быть унифицирован и контролироваться из одной точки, то можно отключить автоапдейт VMware Tools. Делается это так:
VMwareToolboxCmd.exe config set autoupgrade allow-upgrade false
VMwareToolboxCmd.exe config set autoupgrade allow-add-feature false
VMwareToolboxCmd.exe config set autoupgrade allow-remove-feature false
3. Отключить возможность кастомизации ОС при клонировании
Такая опция позволяет изменять параметры виртуальной машины и гостевой системы, что может быть выгодно злоумышленнику. Отключить кастомизацию ВМ можно следующей командой:
VMwareToolboxCmd.exe config set deployPkg enable-customization false
4. Контроль над информацией, предоставляемой через Appinfo
Об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается).
Отключить Appinfo в виртуальной машине можно следующей командой VMware Tools:
VMwareToolboxCmd.exe config set appinfo disabled true
5. Отключить Guest Operations (оно же Invoke-VMScript)
Командлет Invoke-VMScript - это мощный механизм для разработчиков, позволяющий работать с гостевой системой виртуальной машины со стороны механизма сценариев PowerCLI. Очевидно, что этот интерфейс расширяет поверхность потенциальной атаки, и если вы им не пользуетесь, то его лучше отключить. Делается это следующей командой:
VMwareToolboxCmd.exe config set guestoperations disabled true
6. Отключение ненужных компонентов
Это базовое правило - чем меньше компонентов VMware Tools у вас установлено, тем меньше вероятность, что через какой-то из них произойдет атака. Например, не всем пользователям и администраторам нужны такие возможности, как Service Discovery, AppDefense и Shared Folders. Но здесь, очевидно, нужно соблюдать разумный баланс - не надо отключать что-то нужное, о чем вы потом будете думать: "почему оно не работает?".
Подробнее об отключении компонентов VMware Tools при развертывании через утилиту командной строки написано тут.
Некоторые функции vCloud Director (VCD) по работе с виртуальными машинами по-прежнему недоступны через стандартные командлеты PowerCLI, поэтому к ним необходимо обращаться через VCD API.
Jon Waite в своем блоге опубликовал PowerCLI-сценарий, с помощью которого можно обратиться к VCD API и увеличить размер загрузочного диска ВМ. Надо сказать, что при подобного рода манипуляциях (как увеличение, так и уменьшение диска) всегда есть риск потери данных, поэтому обязательно сделайте резервную копию.
Стандартное определение функции - на входе объект виртуальная машина и новый желаемый размер первого (загрузочного) диска в МБ.
7-9
Одна команда, разделенная на 3 строчки. Вызов VCD API для определения поддерживаемых версий API, чтобы не хардкодить конкретную версию в скрипте.
10-12
Обрабатывает результат прошлой строчки, определяет последнюю актуальную версию VCD API и сохраняет $APIVersion для использования позднее.
14
Определяет SessionId для текущей сессии PowerCLI (Connect-CIServer), чтобы использовать API-запросы на строчках 17 и 27.
15
Получает хэш $Headers для отправки API-запросов (переменные SessionId и APIVersion были получены ранее).
16
Определяет API URI через поддерживаемый VM HTTP reference.
17
Получает представление XML секций virtualHardwareSection/disks определенной ВМ.
19-20
Находит первый диск, привязанный к ВМ (ResourceType 17 = Hard Disk)
22-23
Обновляет размер диска ВМ на базе входного параметра емкости у функции. На самом деле у VCD достаточно обновить capacity, а VirtualQuantity обновляем для консистентности (в байтах).
24
Добавляем дополнительное значение к $Header, чтобы обозначить Content-Type, который мы отправляем обратно к API.
26-34
Попытки обновить API измененным XML, включая новый размер диска и возвращаем ошибку с описанием, если операция прошла неудачно.
После выполнения сценария нужно будет, само собой, расширить соответствующий раздел гостевой системы. Современные версии Windows и Linux могут раскатывать существующий раздел на весь размер физического устройства даже без перезагрузки машины.
Пример использования сценария:
PS /> $VM = Get-CIVM -Name 'TestVM01'
PS /> $VM | Update-CIVMBootDisk -NewSizeMB 2048
Disk resize for VM TestVM01 submitted successfully.
Некоторым администраторам может понадобиться PowerCLI-сценарий, с помощью которого можно подсчитать число гостевых операционных систем в виртуальных машинах инфраструктуры VMware vSphere. Stuart в своем блоге рассказал про интересный скрипт, с помощью которого это можно сделать.
Начал он с того, что в переменную $server2012 он записал количество гостевых операционных систем определенного типа с помощью команды:
$server2012 = ((get-vm).extensiondata.guest | Where GuestFullName -eq "Microsoft Windows Server 2012 (64-bit)").count
Далее он стал думать, как сделать таблицу со всеми ОС, для этого решил создать хэш-таблицу, куда будут записываться типы гостевых ОС и их количество:
После этого он сделал скрипт, который собирает в таблицу типы гостевых ОС и увеличивает счетчик, если они встречаются среди виртуальных машин снова при прогоне цикла:
В этой таблице все в порядке, кроме последней строчки - в нее набиваются гостевые ОС, для которых тип не был обнаружен. Поэтому автор добавил следующие строчки с именами ВМ, чтобы добавить значение Unknown таким машинам:
# Added this to the beginning of the script
$NullOS = Get-Content C:\Scripts\Logs\Guestfullname.txt
# Added this to the foreach loop section
IF ($OSName -eq $NullOS){$OSName = "Unknown"}
Как знает большинство администраторов VMware vSphere, у данной платформы есть очень удобная сущность Content Library, которая позволяет хранить контент различного типа (скрипты, ISO-образы, текстовые файлы), в том числе шаблоны виртуальных машин. В обновленном решении VMware vSphere 7 появилось несколько новых возможностей по работе с библиотеками, о которых мы рассказывали вкратце, а сегодня поговорим подробнее.
Первое важное нововведение - представление для управления шаблонами, в котором доступны функции Check-In и Check-Out для работы с версиями шаблонов и возможностью откатиться к предыдущей версии.
Ранее при работе с шаблонами в формате VM Template (*.vmtx) администратор vSphere должен был выполнить следующую последовательность действий:
Конвертировать шаблон в виртуальную машину
Сделать снапшот ВМ на случай того, что что-то пойдет не так
Обновить гостевую ОС или другие настройки ВМ
Конвертировать ВМ назад в шаблон
Скопировать шаблон обратно в Content Library
Удалить старый шаблон из библиотеки
Теперь это все выглядит гораздо проще. Для внесения изменений в шаблон нужно сделать просто Check-Out его из библиотеки:
Этот процесс вовлекает последовательность действий, но даже во время нее можно развертывать новые ВМ из этого шаблона (просто остальные пользователи не могут сделать Check-Out).
Далее администратор может изменять шаблон и чекинить его обратно в библиотеку, а также создавать новые версии этого шаблона, чтобы можно было использовать несколько модификаций одного шаблона. Также при Check-In шаблона можно указать, что в нем изменилось, чтобы другие пользователи были в курсе:
После этого создается цепочка версий с временными метками, где можно отслеживать всю историю изменений шаблона ВМ:
Версионирование позволяет откатиться к любой версии шаблона, а также удалить ее из цепочки:
Кроме того, теперь у Content Library появились расширенные настройки (Advanced Configuration), доступ к которым можно получить вот тут:
Сами настройки выглядят так (можно выбрать один из серверов vCenter, где изменяются настройки):
Обратите внимание, что для применения некоторых настроек нужно будет перезагрузить сервис Content Library. Делается это из интерфейса vCenter Appliance Management Interface (VAMI). Для этого вас перенаправят на страницу https://<vCenterServer-FQDN>:5480:
Также в vSphere 7 был улучшен механизм привилегий для библиотек контента:
Ну и напоследок отметим, что еще в PowerCLI 11.5 появилось несколько новых командлетов для управления библиотеками контента. В PowerCLI 12 все еще лучше.
В начале апреля компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью командных сценариев PowerShell до версии PowerCLI 12.0. Напомним, что прошлая версия PowerCLI 11.5 вышла осенью прошлого года.
Давайте посмотрим, что нового появилось в двенадцатой версии фреймворка:
Добавлены командлеты для управления хостовой сетью ESXi
Еще в vSphere 6.0 появилась поддержка сетевых стеков хостов ESXi. Она позволяет назначить различные шлюзы для адаптеров VMkernel в целях маршрутизации трафика. Через PowerCLI можно использовать ESXCLI или API для управления этой функциональностью с помощью командлетов Get-VMHostNetworkStack и Set-VMHostNetworkStack. Новый параметр называется "NetworkStack", он был добавлен в командлет New-VMHostNetworkAdapter:
Добавлены командлеты для управления решением HCX
Появились новые командлеты для управления пространствами имен
Командлеты для управления службами Trusted Host Services
Командлеты для управления диском гостевой ОС виртуальных машин (VM Guest Disk management)
Теперь раздел гостевой ОС можно замапить на VMDK-диск (пока только для Windows-систем). Для этого потребуется vSphere 7 и VMware Tools не ниже 11-й версии. Эту возможность можно использовать с помощью командлета Get-VMGuestDisk:
Новые командлеты для управления VMware Cloud on AWS
Новые командлеты для vSAN:
Get-VsanFileServiceDomain
New-VsanFileServiceDomain
Set-VsanFileServiceDomain
Remove-VsanFileServiceDomain
New-VsanFileServiceIpConfig
Get-VsanFileShare
New-VsanFileShare
Set-VsanFileShare
Remove-VsanFileShare
New-VsanFileShareNetworkPermission
Add-VsanFileServiceOvf
Get-VsanFileServiceOvfInfo
Новый модуль для управления службами VMware Cloud Services
Добавлена поддержка vSphere 7.0
Добавлена поддержка vRealize Operations 8.0
Обновлена поддержка модулей License и vROps, а также командлета Open-VMConsoleWindow для использования на различных платформах
Поддержка Move-VM для сетей opaque networks
Добавлена поддержка последних обновлений PowerShell 7.0:
Скачать VMware PowerCLI 12.0 можно по этой ссылке. Полезные ресурсы:
Многие из вас знакомы с решением VMware App Volumes, которое предназначено для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. Те из вас, кто его используют, время от времени, наверняка, сталкиваются с проблемой недостатка места на пользовательских томах Writable Volumes, которые забиваются неизвестно чем:
Напомним, что Writable Volumes - это персонализированные тома, которые принадлежат пользователям. Они хранят настройки приложений, лицензионную информацию, файлы конфигураций приложений и сами приложения, которые пользователь установил самостоятельно. Один такой диск может быть назначен только одному десктопу, но его можно перемещать между десктопами. Соответственно, такие тома могут легко заполняться, и пользователи начинают жаловаться.
Aresh Sarkari написал полезный скрипт, который выявляет заполненные тома Writable Volumes в инфраструктуре App Volumes (меньше 3 ГБ свободного места), формирует CSV-файл с данными о них и посылает его по электронной почте администратору:
####################################################################
# Get List of Writable Volumes from AppVolumes Manager for free space less than 3 GB out of 30 GB
# Author - Aresh Sarkari (@askaresh)
# Version - V2.0
####################################################################
# Run at the start of each script to import the credentials
$Credentials = IMPORT-CLIXML "C:\Scripts\Secure-Creds\SCred_avmgr.xml"
$RESTAPIUser = $Credentials.UserName
$RESTAPIPassword = $Credentials.GetNetworkCredential().Password
$body = @{
username = “$RESTAPIUser"
password = “$RESTAPIPassword”
}
Invoke-RestMethod -SessionVariable DaLogin -Method Post -Uri "https://avolmanager.askaresh.com/cv_api/sessions” -Body $body
$output = Invoke-RestMethod -WebSession $DaLogin -Method Get -Uri "https://avolmanager.askaresh.com/cv_api/writables" -ContentType "application/json"
$output.datastores.writable_volumes | Select-Object owner_name, owner_upn,total_mb, free_mb, percent_available, status | Where-Object {$_.free_mb -lt 3072} | Export-Csv -NoTypeInformation -Append D:\Aresh\Writableslt3gb.$(Get-Date -Format "yyyyMMddHHmm").csv
#send an email (provided the smtp server is reachable from where ever you are running this script)
$emailfrom = 'writablevolumes@askaresh.com'
$emailto = 'email1@askaresh.com', 'email2@askaresh.com' #Enter your SMTP Details
$emailsub = 'Wrtiable Volumes Size (free_mb) less than 3 GB out of 30 GB - 24 Hours'
$emailbody = 'Attached CSV File from App Volumes Manager. The attachment included the API response for all the Writable Volumes less than 3 GB of free space'
$emailattach = "D:\Aresh\Writableslt3gb.$(Get-Date -Format "yyyyMMddHHmm").csv"
$emailsmtp = 'smtp.askaresh.com'
Send-MailMessage -From $emailfrom -To $emailto -Subject $emailsub -Body $emailbody -Attachments $emailattach -Priority High -DeliveryNotificationOption OnFailure -SmtpServer $emailsmtp
Последняя версия сценария PowerCLI для поиска заполненных томов доступна в репозитории на GitHub. Там же, кстати, есть сценарий для поиска Writable Volumes со статусом Disabled или Orphaned.
Не так давно компания VMware выпустила обновление пакетов продуктов vRealize Suite и vClud Suite, в состав которых входит средство VMware vRealize Orchestrator 8.1. Напомним, что это средство предназначено для автоматизации рабочих процессов в виртуальной инфраструктуре за счет скриптования и оркестрации последовательности рутинных операций при управлении виртуальной средой.
Давайте посмотрим, что нового появилось в vRO 8.1:
Древовидное представление иерархических папок. Функция, которая была в более ранних версиях и потом пропала из vRO, теперь вернулась и позволяет пользователям удобно организовывать и просматривать объекты в виде дерева.
Элементы Run и Debug для рабочих процессов. Пользователи могут выполнить действия запуска и отладки без необходимости их добавления в рабочий процесс.
Схема Debug workflow - теперь можно добавлять точки останова к определенным элементам в схемах для рабочих процессов.
Возможность пуша набора изменений в бранчи Git. При работе с версиями контента в репозитории Git, vRO позволяет пользователям выбрать, настроить и запушить изменения в разные бранчи. Для данной функции нужна лицензия vRealize Automation.
Несколько языков для скриптов: PowerShell, Node.js, Python. vRealize Orchestrator 8.1 добавляет поддержку PowerCLI 11/Powershell 6.2, Node.js 12, and Python 3.7. Для этого также нужна лицензия vRealize Automation.
Поддержка сервиса Syslog - можно настроить интеграцию со службами логирования для одного или нескольких удаленных серверов syslog.
Графическое сравнение версий схем рабочих процессов - теперь эта возможность позволяет наглядно определить, какие изменения были внесены в следующую версию workflow.
Апдейт API плагинов для поддержки vSphere 6.7.
Скачать VMware vRealize Orchestrator 8.1 можно по этой ссылке. Release Notes доступны тут.
Как все уже знают, VMware vSphere 7 вышла, доступна для скачивания и уже обкатывается многими администраторами виртуальных инфраструктур. Для тех, кто еще не знает, поддерживает ли текущее оборудование новый гипервизор ESXi 7, Florian Grehl сделал специальный сценарий PowerCLI, который позволяет вывести эту информацию для серверов кластера:
Сценарий доступен в репозитории на GitHub. Скрипт автоматически загружает функцию HCL-Check (из GitHub), а также JSON-файл для VMware HCL. В переменной $scope можно установить серверы, которые будут проверены (по умолчанию проверяется все окружение vCenter).
Надо понимать, что если ваш хост не поддерживается для VMware ESXi 7, то имеет смысл проверить его еще раз на всякий случай в реальном VMware HCL.
Если вы получаете вот такое сообщение об ошибке:
.\check_esxi_70_support.ps1 : File .\check_esxi_70_support.ps1 cannot be loaded. The file is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.
Значит нужно в свойствах скрипта разблокировать его:
Мы много писали о том, что нового появилось в обновленной платформе виртуализации VMware vSphere 7, которая недавно стала доступной для загрузки. Сегодня мы поговорим о том, чего больше нет в vSphere, ведь многие администраторы привыкли использовать некоторые средства, поэтому, возможно, подождут с апгрейдом. Об этих запланированных изменениях мы писали еще в 2017 году.
1. Больше нет vSphere Web Client на базе Flash
Об этом говорили давно, долго задерживали снятие с производства тяжеловесного vSphere Web Client, но все откладывали из-за несоответствия функциональности клиенту нового поколения vSphere Client на базе технологии HTML5. Теперь в vSphere 7 этот переход окончательно завершен, и старого Web Client больше нет.
Клиент на HTML5 включает в себя не только все старые рабочие процессы Web Client, но и давно получил новые возможности, такие как, например, упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).
2. Больше нет внешнего PSC (Platform Services Controller)
Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).
С помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:
3. Больше нет VMware vCenter for Windows
Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь остался только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS. Многие привыкли к сервисам vCenter на базе Windows, теперь придется отвыкать.
VMware рекомендует выполнить 2 основных шага для миграции с vCenter на vCSA:
Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.
4. Больше нет Update Manager Plugin
На протяжении долгого времени это был плагин для vSphere Web Client. Теперь вместо продукта VMware Update Manager (VUM) в vSphere 7 есть более широкое по функциональности решение VMware Lifecycle Manager.
Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.
5. Больше нет VNC-сервера в ESXi
Ранее в ESXi был встроенный VNC-сервер, который был убран в последней версии VMware vSphere 7. Раньше можно было соединиться с консолью виртуальной машины с помощью VNC-клиента, добавив в конфигурацию параметр RemoteDisplay.vnc.enable.
Теперь такой возможности больше нет (ей пользовались администраторы систем, не использующих средства VMware). Для соединения с консолью виртуальной машины используйте vSphere Client, хостовый клиент ESXi Host Client или средство VMware Remote Console.
6. Мелочи, которых или уже больше нет или их не рекомендуется использовать (не будет потом)
В эту категорию попали:
VMware vSphere 7.0 и протокол TLS Protocol (TLS 1.0 и 1.1 отключены по умолчанию).
Нет поддержки резервного копирования на уровне образов (Image-Based Backup) для сервера vCenter.
Интерфейс VMKlinux API уже давно безнадежно устарел, вместо него используется архитектура нативных драйверов под vSphere, начиная еще с ESXi 5.5. vmkLinux - это такая прослойка между VMkernel и Linux-драйверами, которая позволяла транслировать команды от ядра (так как VMkernel - это НЕ Linux) к драйверам и обратно. Но теперь нативных партнерских драйверов устройств для ESXi накопилось достаточно, и старая архитектура Linux-драйверов ушла в прошлое.
Депрекация поддержки 32-bit Userworld. Ранее партнерам VMware была доступна возможность делать 32-битные драйверы, плагины и другие компоненты в VIB-пакетах. Теперь, начиная со следующих версий vSphere, такой возможности больше не будет.
Почти убрана поддержка Integrated Windows Authentication. В этой версии IWA еще работает, но в следующей версии уже не будет. Подробнее в KB 78506.
Депрекация аутентификации DCUI Smart Card Authentication. Пользователям со смарт-картами рекомендовано использовать vCenter, PowerCLI или API-вызовы, ну либо логин и пароль по-старинке.
Депрекация Core Partition Profile для функциональности Host Profiles. Вместо разделов Coredump Partitions пользователям нужно использовать файлы Coredump Files.
На днях, как вы знаете, было много интересных новостей. И вот еще одна - компания VMware анонсировала большое обновление своей флагманской платформы виртуализации VMware vSphere 7. Напомним, что прошлая мажорная версия этого решения VMware vSphere 6.7 вышла весной 2018 года.
Сразу скажем, что это лишь анонс, а не объявление о доступности новой версии продукта для скачивания - как правило, GA версия vSphere появляется в течение месяца после анонса. Поэтому будем пока ожидать VMware vSphere 7 в апреле, а сегодня расскажем о новых возможностях этой платформы.
1. Улучшения сервисов VMware vCenter
Здесь можно отметить упрощение топологии vCenter Server SSO:
Возможность апгрейда vCenter Server для пользователей с внешним PSC на консолидированную топологию на базе одного сервера vCSA.
Embedded PSC теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается.
Профили vCenter Server Profiles:
Эта новая возможность для серверов vCenter работает точно так же, как Host Profiles работает для хостов. Теперь вы можете сравнивать и экспортировать настройки серверов vCenter в формате JSON для целей резервного копирования или применения этих настроек к другому серверу vCenter через REST API.
Функции vCenter Multi-Homing:
Теперь для управляющего трафика vCSA можно использовать до 4 адаптеров vNIC, среди которых один vNIC зарезервирован для механизма vCHA.
Улучшения Content Library
Теперь появилось новое представление для управления шаблонами, в котором доступны функции Check-In и Check-Out для управления версиями шаблонов и возможностью откатиться к предыдущей версии.
Сначала делается Check-Out для открытия возможности внесения изменений, потом можно сделать Check-In для сохранения изменений в библиотеке.
Новая функция vCenter Server Update Planner:
Новая возможность доступна как часть vSphere Lifecycle Manager (vLCM) для серверов vCenter.
С помощью планировщика обновлений можно получать оповещения об обновлениях vCenter, планировать апгрейды, накатывать их, а также проводить анализ "что если" перед проведением обновления.
Возможность выполнения pre-upgrade проверок для выбранного сервера vCenter.
2 Улучшения механизма VMware DRS
Теперь DRS запускается каждую минуту, а не каждые 5 минут, как раньше.
Для генерации рекомендаций используется механизм VM DRS score (он же VM Hapiness).
Теперь это Workload centric механизм - это означает, что теперь в первую очередь учитываются потребности самой виртуальной машины и приложения в ней, а только потом использование ресурсов хоста.
Расчеты по памяти основываются на granted memory вместо стандартного отклонения по кластеру.
Появился механизм Scaleable Shares, который позволяет лучше выделать Shares в пуле ресурсов с точки зрения их балансировки.
3. Улучшения vMotion
Тут появились такие улучшения:
Улучшения миграций для Monster VM (с большими ресурсами и очень высокой нагрузкой), что позволяет увеличить шанс успешной миграции.
Использование только одного vCPU при отслеживании изменившихся страниц (page tracer) вместо всех vCPU, что меньше влияет на производительность во время миграции.
Уменьшение времени переключения контекста на другой сервер (теперь меньше одной секунды). Достигается за счет переключения в тот момент, когда compacted memory bitmap уже передана на целевой сервер, вместо ожидания передачи full bitmap.
4. Новые функции vSphere Lifecycle Manager (vLCM)
Здесь можно отметить 2 улучшения:
Функция Cluster Image Management, которая включает обновления firmware, драйверов и образов ESXi разных версий.
Первоначальная поддержка решений Dell OpenManage и HP OneView.
5. Возможности Application Acceleration (Tech Preview)
Эти функции пришли от приобретенной компании Bitfusion. Они позволяют оптимизировать использование GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может использоваться для рабочих нагрузок задач приложений AI/ML.
Все это позволяет организовать вычисления таким образом, что хосты ESXi с аппаратными модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При этом CUDA-инструкции от клиентских ВМ передаются серверным по сети. Подробнее можно почитать у нас тут.
6. Функции Assignable Hardware
Эта возможность позволяет использовать так называемый Dynamic DirectPath I/O для машин, которым требуется работа с устройствами PCIe passthrough и Nvidia GRID. Теперь с его помощью можно подобрать хосты с определенными требованиями к аппаратным компонентам, такими как vGPU и PCIe. Это позволяет, в свою очередь, использовать для таких ВМ технологии HA и DRS Initial Placement в кластере, где есть совместимые по оборудованию хосты ESXi.
7. Управление сертификатами
Здесь 2 основных новых возможности:
Новый мастер импорта сертификатов.
Certificate API для управления сертификатами с помощью сценариев.
8. Возможности Identity Federation
Функции ADFS теперь поддерживаются из коробки, также будет поддерживаться больше IDP, использующих механизмы OAUTH2 и OIDC.
9. Функции vSphere Trust Authority (vTA)
vTA использует отдельный кластер хостов ESXi, чтобы создать отдельный аппаратный узел доверия.
Этот кластер сможет зашифровывать вычислительный кластер и его ВМ вместе с vCenter и другими управляющими компонентами.
Можно использовать механизм аттестации, когда требуются ключи шифрования.
Теперь проще добиться соблюдения принципа наименьших привилегий, а также расширить пространство аудита.
10. Возможность vSGX / Secures Enclaves (Intel)
Расширения Intel Software Guard Extensions (SGX) позволяют переместить чувствительную логику и хранилище приложения в защищенную область, к которой не имеют доступа гостевые ОС и гипервизор ESXi.
Возможности SGX исключают использование vMotion, снапшотов, Fault Tolerance и других технологий. Поэтому SGX лучше использовать только тогда, когда по-другому нельзя.
11. Новое издание vSphere with Kubernetes (Project Pacific)
О Project Pacific мы подробно рассказывали вот тут. Он представляет собой набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes. vCenter Server предоставляет возможности по управлению кластерами k8s (любые кластеры старше n-2 будут обновлены). Также в решение интегрирован Harbor, который может быть включен для каждого пространства имен.
Доступно это пока только для пользователей VMware Cloud Foundation (4.0), так как решение завязано на компонент VMware NSX-T.
12. Улучшения VMware Tools
Функции Guest Store теперь доступны в гостевой ОС (такие как обновление VMware Tools из гостевой ОС).
13. Обновленное железо (VM Hardware v17)
Тут основные улучшения таковы:
Virtual Watchdog Timer - теперь нет зависимости от физического железа для рестарта ВМ в случае, если гостевая ОС не отвечает.
Precision Time Protocol (PTP) - для приложений очень чувствительных ко времени (например, торговые платформы для трейдеров) можно использовать PTP вместо NTP и назначать его использование для виртуальных машин.
14. Улучшения vSphere Client
Здесь появились следующие улучшения:
Начала сохраняться история поиска.
В API Explorer теперь лучше видны все доступные API.
Для Code Capture появилась возможность выбора языка сценариев - PowerCLI, Javascript, Python или Go.
Конечно же, это далеко не все новые возможности VMware vSphere 7, представленные на днях. В ближайшее время мы расскажем еще много нового о них, а кроме того, посмотрим также и на анонсированные решения семейства VMware Tanzu, VMware Cloud Foundation 4 и vRealize 8.1.
Cody Hosterman, известный своими заметками про PowerCLI, написал интересную статью о том, как запоминать дефолтные параметры на примере свойств соединения с дисковым массивом. Это может вам оказаться полезным, например, в случае если вы работаете с дисковым массивом в интерактивном режиме, при этом не хотите каждый раз указывать параметры соединения.
К примеру, при использовании модуля PureStorage.FlashArray.VMware есть возможность передавать параметры соединения, сохраненные в глобальной переменной $Global:DefaultFlashArray. Неудобство этого метода в том, что каждый раз вы должны указывать параметр -Array:
Поэтому в PowerCLI заложен отличный механизм дефолтных параметров для нужных вам командлетов. Например, можно создать переменную с параметрами соединения с массивом:
Далее можно записать эту переменную в дефолтные параметры:
$PSDefaultParameterValues = @{
"*-pfa*:Array"=$flashArray;
}
Это позволит для параметра, называющегося Array применять параметры соединения из переменной $flashArray. При этом эти параметры будут применяться только для командлетов, содержащих "-pfa" в своем названии (они есть только в модуле PureStoragePowerShellSDK).
Для всего модуля и всех командлетов нет простого способа задать дефолтные параметры, но можно получить в сценарии список всех доступных командлетов и для всех них прописать правило использования параметра -Array:
После этого вы сможете просто использовать командлеты без параметров, например, Get-PfaVolumes, чтобы получить все тома с заданного в дефолтном соединении массива:
Аналогично способ будет работать и для всех остальных параметров командлетов и любых других модулей.
На сайте проекта VMware Labs появилась обновленная версия веб-клиента для управления платформой VMware vSphere - HTML5 Web Client 5.0 (он же vSphere Client в релизной редакции vSphere). Напомним, что прошлая версия vSphere Client 4.3 вышла еще в сентябре прошлого года.
Давайте посмотрим, что нового появилось в основном клиенте vSphere, функции которого будут включены в очередной крупный апдейт платформы:
Новый язык для механизма Code Capture - теперь запись происходящего в интерфейсе может быть транслирована в код на языке Go.
Операционная система виртуального модуля клиента заменена на Photon OS. Соответственно, обновления на версию 5.0 с более ранних версий не поддерживаются.
Функция PowerActions - теперь PowerCLI и vSphere Client будут плотно интегрированы (см. раздел Developer Center). Это позволяет исполнять сценарии PowerCLI прямо из vSphere Client, а также сохранять их в библиотеке. Кастомные действия, которые записаны как PowerCLI-сценарии, теперь можно выполнять для заданных объектов из инвентори.
Чтобы PowerActions заработали, нужно их явно включить во время развертывания виртуального модуля vSphere Client. Для того, чтобы узнать больше об этом механизме, прочитайте документ PowerActions_documentation_Fling50.pdf из состава дистрибутива.
Скачать VMware vSphere Client 5.0 можно по этой ссылке. Там же, выбрав из комбо-бокса, можно загрузить и всю необходимую документацию.
Не все администраторы виртуальной инфраструктуры VMware vSphere в курсе, что в этой платформе доступен удобный инструмент, который позволяет сгенерировать PowerCLI-сценарий из последовательности действий, которые выполняет администратор в интерфейсе vSphere Client.
Эта функция называется Code Capture, и появилась она весной прошлого года в обновлении платформы VMware vSphere 6.7 Update 2, о которой мы писали вот тут. Этот механизм VMware тестировала еще в далеком 2009 году, тогда он назывался Project Onyx.
Чтобы получить доступ к этой фиче, нужно в меню vSphere Client выбрать пункт Developer Center, где есть переключатель Enable Code Capture:
После того, как вы включите Code Capture, в верхнем тулбаре клиента появится красная кнопка записи:
Например, можно нажать на нее и, как показано на скриншоте выше, запустить клонирование виртуальной машины, а затем включить созданную ВМ.
После того, как вы запишете сессию, можно нажать кнопку Stop Recording, после чего будет сгенерирован PowerCLI-сценарий, с помощью которого можно автоматизировать развертывание новой машины:
Полученный скрипт можно скопировать или скачать для последующего его изменения уже в собственном редакторе. Надо отметить, что поскольку сценарий генерируется автоматически - он получается далеко не самым оптимальным с точки зрения структуры и времени работы. Поэтому если вы умеете разрабатывать сценарии на PowerCLI, то лучше делать их вручную с нуля. С другой стороны, не все действия в клиенте понятно, как автоматизировать, и какие командлеты использовать - поэтому Code Capture определенно может помочь подобрать нужные.
Если хочется сделать сценарий по-новой, то можно нажать кнопку "Clear and start another" - это удалит прошлый скрипт (не забудьте сохранить его, если он нужен) и начнет новую сессию записи.
Чтобы отключить функцию code capture для всех пользователей, нужно добавить строчку "codecapture.disabled=true" в файл конфигурации клиента vSphere Client (надо будет его перезапустить): /etc/vmware/vsphere-client/vsphere-client/webclient.properties.
Интересный баг обнаружил Matt для своей виртуальной инфраструктуры, когда пытался клонировать виртуальные машины с выставленной опцией "customize this virtual machine’s hardware":
Оказалось, что после создания клона его VMDK-диск указывал на VMDK клонируемой машины, что, само собой, является серьезнейшим багом. После работы с техподдержкой оказалось, что баг не такой и частый, так как проявляется только когда в VMX-файле исходной машины параметр disk.enableuuid выставлен в значение TRUE (по умолчанию он отсутствует и применяется как FALSE).
Данный параметр иногда добавляется пользователями в соответствии с рекомендациями вендоров решений для резервного копирования и управления виртуальной средой - он позволяет убедиться в том, что VMDK диск предоставляет машине консистентный UUID для корректного монтирования.
Workaround для этого бага - это либо использовать для операций клонирования старый vSphere Web Client, либо делать это через PowerCLI. Можно также не использовать опцию "customize this virtual machine’s hardware", а настроить железо ВМ после выполнения клонирования. Также баг не проявляется если делать клонирование выключенной машины.
Под конец года компания VMware выпустила очередной полезный администраторам VMware vSphere постер - VMware PowerCLI 11 Storage Module Reference Poster for vSAN. В постере приведено несколько полезных командлетов для последней версии PowerCLI, которые позволяют управлять хранилищами VMware vSAN с помощью модуля Storage.
С левой стороны перечислены все командлеты данного модуля, разбитые по группам, а справа приведены примеры использования различных команд и простых сценариев для выполнения типовых задач. Например, показано как узнать емкость датастора vSAN, установить VIB-пакет на хост vSAN или включить функцию vSAN Encryption в кластере.
Скачать постер VMware PowerCLI 11 Storage Module Reference Poster for vSAN можно по этой ссылке.
В сентябре этого года мы писали о новой версии пакета VMware Tools 11 для гостевых ОС виртуальных машин на платформе VMware vSphere. Одной из новых возможностей обновленной версии тулзов был читаемый с хоста параметр AppInfo для публикации информации о запущенных приложений внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается).
Недавно Вильям Ламм пояснил, как именно может работать этот механизм, который дает возможность получить данные о процессах в гостевой ОС и их свойствах.
Для начала начала надо включить Application Discovery в гостевой ОС с помощью утилиты VMwareToolbox. По умолчанию этот механизм отключен, чтобы не создавать дополнительную нагрузку на виртуальную машину.
Для включения нужно выполнить следующую команду:
Windows: VMwareToolboxCmd.exe config set appinfo enabled true
Linux: vmware-toolbox-cmd config set appinfo enabled true
Выглядит это таким образом:
После того, как сбор данных включен, они будут обновляться каждые 30 минут - то есть эта функция не предназначена для мониторинга процессов в реальном времени, а скорее для сбора информации об имеющихся в ВМ приложениях и их свойствах. Чтобы изменить интервал обновления, используйте следующие команды:
Linux: vmware-toolbox-cmd config set appinfo poll-interval <new value in seconds>
Windows: VMwareToolboxCmd.exe config set appinfo poll-interval <new value in seconds>
Например, AppInfo может собирать информацию о версии всех приложений, что может оказаться полезным при автоматизированном поиске устаревших версий приложений с помощью сценариев.
Вильям написал PowerCLI-скрипт Get-VMApplicationInfo.ps1, который принимает на вход виртуальную машину, а на выходе выдает информацию о процессах гостевой ОС с меткой времени сбора данных.
Результат работы сценария можно вывести в CSV-файл или в JSON-массив.
Ну а дальше уже можно фантазировать, для чего подобная информация может пригодиться именно в вашей виртуальной инфраструктуре.
Вильям Ламм написал интересную статью про вывод информации обо всех доступных событиях на сервере VMware vCenter. Недавно мы писали о решении vCenter Event Broker Appliance (VEBA), которое позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That".
Так вот, администраторы, использующие VEBA, часто задают вопрос о том, как найти конкретное событие vCenter и его ID в целях автоматизации операций. Также иногда это необходимо для использования с vSphere API. Для этого Вильям написал PowerCLI скрипт, который экспортирует список всех происходивших событий vCenter в CSV-файл, где в отдельных колонках приведены EventId, EventType (может быть Standard, EventEx или ExtendedEvent) и EventDescription:
Пример результатов работы данного сценария как для VMware vCenter 6.7 Update 3, так и для облачной среды VMware Cloud on AWS 1.8, можно найти в репозитории по этой ссылке: https://github.com/lamw/vcenter-event-mapping.
На скриншоте видно, что в поле Description отображается не то, что было задано в свойствах события. Это связано с тем, что за отображение этого поля отвечает другая подсистема. Чтобы это поле корректно отображалось для кастомных событий нужно зарегистрировать кастомное расширение (custom extension), которое будет публиковать информацию о событии. Более подробную информацию об ExtensionManager, с помощью которого это можно сделать, можно посмотреть вот тут.
Большинство сценариев PowerCLI начинаются с команды Connect-VIServer. Она позволяет соединиться с нужным сервером VMware vCenter и исполнять там необходимые сценарии.
Если вы работаете только с одним сервером vCenter, то нужно лишь один раз соединиться с сервером и после этого выполнять там команды без его указания. Для удобства работы в таких окружениях разработчики обычно прописывают глобальную переменную $global:DefaultVIServer, где указывают сервер vCenter по умолчанию. Это дает возможность исполнять командлеты без указания сервера vCenter, который будет подставляться из глобальной переменной.
Если из сценария PowerCLI вы соединяетесь с несколькими серверами vCenter одновременно, то для выполнения команды на нужном vCenter, надо указать его явно:
Get-VM -Server vcenter1.domain.local
В то же время, если вы пользуетесь глобальной переменной DefaultVIServer, вы можете попасть в ситуацию, когда использование ее станет невозможным, поскольку она очищается при дисконнекте от сервера vCenter. Рассмотрим пример:
Connecting to vCenter server vcenter1.domain.local
DefaultVIServer value: vcenter1.domain.local
Connecting to vCenter server vcenter2.domain.local
DefaultVIServer value: vcenter2.domain.local
Disconnecting from vCenter server vcenter2.domain.local
DefaultVIServer value:
Get-VM : 29/11/2019 6:17:41 PM Get-VM You are not currently connected to any servers. Please connect first using a Connect cmdlet.
Мы видим, что при отключении от сервера vCenter2 произошла очистка переменной DefaultVIServer, поэтому при попытке вызвать командлет Get-VM возникла ошибка. При этом текст ошибки об отсутствии соединения вводит в заблуждение и не соответствует фактической ситуации. Ведь подключение к серверу vCenter1 осталось, просто отсутствует значение этого сервера в переменной DefaultVIServer.
Чтобы работать с несколькими серверами vCenter одновременно, в окружении PowerCLI есть режим Multiple DefaultVIServer mode, который позволяет использовать массив DefaultVIServers.
После перехода в этот режим все команды без указания параметра -Server будут исполняться на всех подключенных серверах vCenter (это надо иметь в виду), присутствующих в массиве DefaultVIServers.
Если же другие пользователи будут выполнять ваш скрипт в режиме Single connection mode, то он может исполняться некорректно или вылететь с ошибкой, поэтому явно указывайте режим Multiple DefaultVIServer mode в самом начале скрипта.
Многим администраторам VMware vSphere иногда требуется собрать некоторые базовые сведения об имеющихся в виртуальной инфраструктуре виртуальных машинах и их гостевых системах. Традиционные способы сбора такой информации применимы лишь частично - ведь стандартный софт для собора ассетов не может взглянуть внутрь хостов ESXi и задокументировать их внутреннюю структуру. Также надо понимать, что софт, использующий ICMP-протокол (а именно команду ping) также не подходит для этой задачи, так как далеко не все системы сегодня отвечают на пинг.
Давайте посмотрим на способы, которые доступны для этой задачи:
1. Функция экспорта в vSphere Client.
Это самое первое, что вам следует сделать для решения проблемы инвентаризации ассетов в виртуальной среде. Кнопка экспорта находится в нижнем правом углу инвентори клиента. С помощью этой фичи можно выгрузить любое представление с нужными колонками в формат CSV:
Здесь вы сможете выгрузить то, чего больше не сможете выгрузить нигде, например, сведения о поддержке TPM, функциях безопасной загрузки Secure Boot для ESXi и гостевых ОС, поддержке Microsoft Device Guard & Credential Guard и функций шифрования VM Encryption.
2. Экспорт через PowerCLI.
PowerCLI, как вы знаете, может все, что может GUI, плюс несколько больше. Поэтому он вам может понадобиться для расширенных параметров виртуальной среды. Основные шаблоны для работы с PowerCLI можно найти здесь.
Вот так, например, работают командлеты Get-VM и Get-VMGuest:
А вот так Get-VMHost:
Результаты работы можно сохранить в текстовый файл с помощью командлета Out-File или в CSV-файл с помощью Export-Csv.
3. Утилита nmap.
Эта утилита знакома всем сетевым администраторам, ведь ей уже более 20 лет. Ее используют как в физической, так и в виртуальной среде для сбора информации о системах и сервисах, висящих на соответствующих портах. Для Linux систем утилита часто поставляется в комплекте дистрибутива, для Windows она доступна тут.
Вот такой командой можно просканировать подсеть:
nmap -sn 192.168.1.0/24
Помните, что такое сканирование может привлечь внимание систем безопасности, и к вам обязательно придет сотрудник соответствующей службы, если такая у вас в компании есть)
4. Утилита RVTools.
Мы часто пишем об этой утилите (последний раз писали тут). Она предназначена для помощи администраторам при выполнении рутинных операций с виртуальной инфраструктурой VMware vSphere в различных аспектах, в том числе документировании.
Вот так выглядит инвентаризация виртуальных машин:
Удобно, что результаты можно сохранить не только в CSV, но и в нативный Excel-формат.
5. Утилита vDocumentation.
Об этой утилите мы писали вот тут. По сути, это набор сценариев, который позволяет через PowerCLI сгенерировать отчетность в форматах CSV или XLS, посвященную различным сторонам виртуальной инфраструктуры (сеть, хосты, кластеры vSAN и т.п.).
6. Утилита vCheck.
Об этой утилите для VMware vSphere мы уже писали вот тут. Кстати, недавно вышла ее версия для инфраструктуры виртуальных ПК VMware Horizon. vCheck - это PowerCLI-скрипт, который готовит отчетность по объектам окружения VMware vSphere и отсылает результат на почту администратора, из которого можно узнать о текущем состоянии виртуальной инфраструктуры и определить потенциальные проблемы.
Бесспорно, всего этого достаточно для сбора сведений об объектах виртуальной инфраструктуры, но не забывайте, что нужно еще иногда инвентаризировать и прочие объекты - интерфейсы iLO/iDRAC, физические коммутаторы, аппаратные сетевые экраны и прочие системы в датацентре.
На днях на сайте проекта VMware Labs появилась очередная новая штука - средство Infrastructure Deployer for vCloud NFV, позволяющее в автоматическом режиме развернуть платформу VMware vCloud NFV (в издании NFV 3.2 VCD) и сконфигурировать ее. Напомним, что NFV - это комплексное решение по виртуализации сетевого стека для сервис-провайдеров (грубо говоря, замена аппаратных роутеров, сетевых экранов и прочих компонентов комплексом из виртуальных машин, предоставляющих динамические сетевые сервисы).
Сам рабочий процесс развертывания основан на архитектуре VMware vCloud NFV 3.0 Reference Architecture и предназначен только для инфраструктуры, развертываемой с нуля (то есть донастроить существующие компоненты не получится).
Сам продукт состоит из двух компонентов:
Входной текстовый файл, в который нужно поместить данные об окружении и компонентах платформы vCloud NFV, которые необходимо развернуть.
Скрипты PowerShell, которые будут исполнены в процессе развертывания.
Для запуска процедуры автоматизированного развертывания потребуется выполнение следующих условий:
Работающий DNS-сервер.
Все компоненты должны иметь актуальные FQDN в DNS.
В инфраструктуре должен функционировать NTP-сервис.
PowerShell не ниже 5.0 и PowerCLI не ниже 10.x.
На Jump VM (там, где запускаются скрипты) должны быть установлены все последние обновления Windows.
Скачать Infrastructure Deployer for vCloud NFV можно по этой ссылке. Там же доступно развернутое руководство пользователя на 57 страницах.
В то же время, у пользователей VMware vCSA есть запрос на автоматизацию процесса резервного копирования средствами PowerCLI через механизм vSphere RESTful API. На блогах VMware появилась интересная статья, описывающая данный процесс, приведем ниже основные его моменты.
Взаимодействие с механизмом резервного копирования vCSA происходит через модуль CIS, который взаимодействует с компонентами инфраструктуры на низком уровне. Первым шагом как раз и является подключение к службе CIS:
Connect-CisServer -Server vcsa01.corp.local
Затем нужно найти сервис, для которого нужно сделать резервную копию:
Get-CisService -Name *backup*
Из вывода видно, что нам нужен сервис com.vmware.appliance.recovery.backup.job. Сохраняем его в переменую и передаем в Get-Member:
В выводе мы видим метод create, который позволяет создать задачу резервного копирования, а также свойство help, которое помогает сформировать входные параметры для задачи РК:
$backupJobSvc.Help.create.piece
Теперь можно заполнить поля задачи данными из нашего окружения. Параметр parts ожидает на вход тип массив, также в параметре password нужно передать специальный тип, чтобы он был принят:
# Login to the CIS Service of the desired VCSA
Connect-CisServer -Server vcsa01.corp.local
# Store the Backup Job Service into a variable
$backupJobSvc = Get-CisService -Name com.vmware.appliance.recovery.backup.job
# Create a specification based on the Help response
$backupSpec = $backupJobSvc.Help.create.piece.CreateExample()
# Fill in each input parameter, as needed
$backupSpec.parts = @("common")
$backupSpec.location_type = "FTP"
$backupSpec.location = "ftp01.corp.local"
$backupSpec.location_user = "backup"
[VMware.VimAutomation.Cis.Core.Types.V1.Secret]$backupSpec.location_password = "VMware1!"
$backupSpec.comment = "PowerCLI Backup Job"
# Create the backup job
$backupJobSvc.create($backupSpec)
Чтобы создать запланированную задачу резервного копирования, надо использовать сервис com.vmware.appliance.recovery.backup.schedules. Тут нам надо задать schedule ID (это строковый параметр по вашему выбору, задается опционально) и заполнить спецификацию аналогично предыдущему сценарию.
Периодичность бэкапа задается через свойство days, которое можно оставить неустановленным (бэкап будет делаться каждый день), либо задать конкретные дни в виде массива.
Ну и, собственно сам сценарий запланированного бэкапа VMware vCSA на уровне файлов через PowerCLI:
# Store the Backup Job Service into a variable
$backupSchedSvc = Get-CisService -Name com.vmware.appliance.recovery.backup.schedules
# Create a Schedule ID specification based on the Help response
$schedSpec = $backupSchedSvc.Help.create.schedule.Create()
$schedSpec = 'weekly'
На днях компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 11.5. Напомним, что о прошлой версии, PowerCLI 11.4, мы писали в конце августа этого года.
Давайте посмотрим, что интересного появилось в PowerCLI 11.5:
1. Новые командлеты для управления библиотеками Content Library.
В последних версиях VMware vSphere функциональность библиотек Content Library была существенно доработана (кстати, это был один из первых сервисов, использовавших vSphere Automation REST API). PowerCLI старается не отставать, поэтому тут было добавлено 8 новых командлетов, а также была добавлена поддержка шаблонов (templates):
New-ContentLibraryItem
Set-ContentLibraryItem
Remove-ContentLibraryItem
Export-ContentLibraryItem
New-ContentLibrary
Set-ContentLibrary
Get-ContentLibrary
Remove-ContentLibrary
Вот пример опроса содержимого объекта библиотеки:
2. Обновление механизма vCenter Alarm Management.
В PowerCLI уже имеются средства для управления алармами vCenter, но их пользователям явно недостаточно. Новая версия PowerCLI имеет 6 новых и 3 обновленных командлета для управления определениями алармов, триггерами, а также для получения данных о типах событий и метриках.
Новые командлеты:
New-AlarmDefinition
Remove-AlarmDefinition
New-AlarmTrigger
Get-AlarmTrigger
Get-EventType
Get-Metric
Обновленные командлеты:
New-AlarmAction
New-AlarmActionTrigger
Set-AlarmDefinition
Вот пример работы нового командлета, где создается определение аларма в vCenter:
3. Обновление модуля VMware Cloud on AWS.
Модуль для управления VMware Cloud on AWS (VMC) - это один из самых новых модулей. Ранее он использовался как средство низкоуровневого взаимодействия с инфраструктурой VMC. Теперь же этот низкоуровневый интерфейс был заменен на высокоуровневые команды для осуществления операций, необходимых пользователю.
Пример - теперь для создания объекта SDDC используется 1 команда вместо 20 строчек кода, которые требовались раньше:
А вот, собственно, новые командлеты, которые появились для VMC (подробнее - здесь):
Get-VmcSddc
Set-VmcSddc
New-VmcSddc
Remove-VmcSddc
Add-VmcSddcHost
Remove-VmcSddcHost
Get-AwsAccount
Get-AwsVpcSubnet
4. Обновленный модуль VMware Core.
Здесь, прежде всего, была доработана функциональность, связанная с тэгами. Командлет Get-Tag и параметр Tag для Get-VM были обновлены, также были обновлены и командлеты Get/Remove-TagAssignment.
Кроме того, базовые функции обогатились некоторыми полезными функциями. Например, теперь при создании виртуальной машины из шаблона средствами командлета New-VM появилась возможность настройки портгруппы через параметры NetworkName или Portgroup.
Также в vSphere 6.7 появилось новое свойство виртуальной машины CreateDate, которое теперь также поддерживается в командлетах, связанных с виртуальной машиной:
Больше информации о новых возможностях VMware PowerCLI 11.5 можно почерпнуть в следующих документах:
На сайте проекта VMware Labs очередное обновление - вышла новая версия продукта Virtual Machine Compute Optimizer 2.0. Это средство представляет собой PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.
Напомним, что о первой версии данной утилиты мы писали летом этого года вот тут. Давайте посмотрим, что нового появилось в Virtual Machine Compute Optimizer 2.0:
Собираются приоритеты найденных несоответствий.
Вывод деталей найденных несоответствий.
Собирается информация о кластере, чтобы определить совместимость оборудования хостов на уровне кластера.
В отчет добавляется информация, если виртуальная машина использует разные физические pNUMA узлы, которые транслируются в гостевую ОС.
Добавляется информация об измененных расширенных настройках на уровне ВМ или хоста ESXi, касающихся представления pNUMA-узлов в гостевую ОС.
В отчет попадают ВМ, если у них число vCPU (с использованием гипертрэдов как vCPU) превышает число физических ядер CPU на хосте ESXi.
Возможность использовать отдельную функцию Get-OptimalvCPU для получения еще большей гибкости.
Скачать VM Compute Optimizer 2.0 можно по этой ссылке. Данный сценарий PowerCLI можно запустить различными способами, смотрите сопровождающий PDF (можно выбрать в комбобоксе при загрузке) для получения более детальной информации.
Большинство из вас, конечно же, слышало о серии уязвимостей в процессорах Intel (например, Meltdown и Spectre), которые потенциально могли приводить к получению контроля над исполнением систем (в том числе виртуальных машин), работающих на базе определенных CPU. Об этом можно прочитать у нас, например, тут и тут.
При обнаружении таких уязвимостей Intel выпускает обновления микрокода (firmware) для своих процессоров, которые нужно применить как к серверам ESXi, так и к виртуальным машинам. Например, для устранения уязвимости типа MDS была добавлена инструкция MD_CLEAR, которую гостевая ОС может обнаружить и использовать для защиты от определенных уязвимостей.
В виртуальной среде виртуальная машина - это VMX-процесс на сервере ESXi, который обеспечивает исполнение гостевой операционной системы. При этом ВМ может перемещаться между серверами ESXi средствами vMotion, поэтому она может иметь довольно большой аптайм (больше самих хостов, где она работает) и, как следствие, долго не обновлять виртуальное аппаратное обеспечение.
В то же время, для патчинга некоторых уязвимостей нужно обновить микрокод CPU и пересоздать VMX-процесс виртуальной машины, чтобы она могла инициализировать и подхватить обновления микрокода (что происходит только при первой загрузке). Простая перезагрузка тут не поможет, так как в этом случае пересоздания VMX не происходит, а лишь идет ребут гостевой системы. Кстати, это вам на заметку - если хотите "почистить" виртуальную машину, то лучше выключить и включить ее, а не перезагружать.
Чтобы выполнить процедуру выключения и включения, начиная с vSphere 6.5 Update 3 и vSphere 6.7 Update 3, компания VMware ввела инструкцию vmx.reboot.PowerCycle, которая выполняет цикл питания виртуальной машины. Этот параметр, который можно добавить в VMX-файл, считывается со стороны VMware Tools, которые уже совместно с хостом ESXi обеспечивают исполнение этого цикла.
Чтобы добавить этот параметр в VMX-файл через PowerCLI, вы можете использовать следующую команду:
Эти команды можно сопроводить принудительным флагом исполнения -Force и контролировать поведение в случае ошибки с помощью -ErrorAction.
После того, как параметр PowerCycle будет выставлен, VMware Tools (вы же помните, что они должны быть установлены) смогут совершить цикл сброса питания для виртуальной машины, а затем сам параметр будет удален из VMX-файла. Также он будет удален автоматически, если вы вручную завершите и снова запустите виртуальную машину.
Для контроля того, что параметр установлен, вы можете посмотреть в vSphere Client, в разделе Configuration Parameters (в самом низу):
Также использование данного параметра может вам помочь в случае кластеров Enhanced vMotion Compatibility (EVC). Такие кластеры требуют от виртуальных машин поддержки единого базового уровня инструкций CPU для обеспечения vMotion между хостами с разным аппаратным обеспечением.
В случае, если у вас где-то поменялось железо на хостах, то нужно выполнить перезапуск цикла питания виртуальных машин, что приведет кластер EVC к единому базовому уровню и позволит избавиться от потенциальных проблем.
RSS
